Design perspective · Product development
This guide explains the development process from a design perspective — what happens at each stage, who is responsible for what, and what the team needs from you to keep things moving.
A note on roles
Throughout this guide, the person responsible for requirements and business decisions is referred to as "Business side." In practice, this could be a Product Manager, a Product Owner, a Business Analyst, or a PO and BA working together.
The role title is less important than the responsibility: someone must own the requirements, someone must sign off at each stage, and someone must be reachable when the design team has questions.
The sequence
✓ = approval required before proceeding · click any phase to read details
UX and UI are different disciplines and they do not overlap. Phases 00 and 01 are UX work: understanding the user, mapping the workflow, validating the logic. No visual design happens there. UI only begins in phase 02, once the UX layer is resolved and approved. Starting visual design before this is the most common cause of expensive revision rounds.
Phase by phase — who does what
Four rules that protect the process
These are not guidelines. They are the conditions under which the process can function. When they are violated, the whole team pays the cost.
Before any design work begins, features are identified and placed into the design pipeline. This is where business decides what needs to be built — and in what order. The Design Lead participates to stay aware of upcoming work, help shape requirements, and plan team capacity.
At this stage, business identifies which features are going into the design pipeline — the Long-Range Plan (LRP). This is not yet about requirements; it is about prioritisation and scheduling.
The most important phase nobody talks about. Before a single frame is designed, the designer needs to understand the problem deeply enough to solve it correctly. This phase is where that understanding is built.
Business enters the preparation phase with a user story that is complete enough for the designer to begin research. Without this, the designer cannot start.
The designer's job in this phase is to understand the problem completely before touching any design tool. Research is not optional — it is what separates a solution from a guess.
There is also an optional but valuable step: the designer studies the user story and reformulates it from a design perspective — breaking the acceptance criteria into discrete blocks that can directly inform the mockup structure.
The development lead may be brought in to validate the mapped workflow before design begins — particularly on complex features where technical constraints might affect the design direction.
This is where the design takes shape — from a rough draft through multiple rounds of validation, to a set of mockups that are ready for development. Approval is not a formality; it is a checkpoint.
The designer produces draft UI mockups — not finished work, but a structured proposal that can be validated and discussed. This is followed by iteration based on feedback from all validating parties.
After approval, the designer produces the final deliverable:
Business side reviews the mockups against the original acceptance criteria. Feedback at this stage is structural — does the design solve the right problem? — not aesthetic.
The development lead reviews the mockups for technical feasibility — catching any design decisions that would be impossible or disproportionately expensive to implement before they reach the full dev team.
QA may be involved at this stage to check whether the acceptance criteria are testable as designed — saving a round of back-and-forth after implementation.
Where possible and appropriate, mockups can be tested with a small group of actual end-users before approval. This is usability testing — not a vote. The goal is to identify friction, not to get consensus.
The moment approved designs move from the design team to the people who will build them. A good hand-off is not a file transfer — it is a conversation. The team that builds the feature needs to understand it, not just receive it.
Before the dev team receives the work, the acceptance criteria must be final. Not "mostly done." Not "we'll clarify during sprint." Final, signed off, and ready to be tested against.
The designer runs a live walkthrough of the design specifically for the team who will build it. This is not a presentation — it is an onboarding. Every person who will touch the feature should understand the design intent, not just see the frames.
The development team — back-end, front-end, and tester — receives the UI mockups linked to the chosen PBI (Product Backlog Item). This is their formal starting point.
The feature is built, tested, and reviewed. This phase has a loop built in: if QA finds issues, the work goes back to the dev team — not to design, not to business. The source of truth remains the approved mockups.
The dev team implements the feature using the UI mockups as the source of truth. Questions go to the designer — not to intuition, not to memory of what was said in a meeting.
The designer remains available throughout implementation — not to redo work, but to answer questions, clarify intent, and catch misinterpretations before they become embedded in the build.
QA conducts a full testing process — not just functional testing, but UI consistency testing against the approved mockups. If issues are found, the feature is returned to the dev team with specific findings. The loop repeats until QA approves.
Once QA and the designer have both approved, business side gives the final sign-off. At this point, the feature is ready for release.
QA checklist
Work through this checklist for every implemented feature. Tick each item as you verify it. The progress bar shows how far through you are.
Shipping is not the finish line. After a feature is released, the team gathers real feedback from real users, measures the outcome against the original goals, and feeds those findings into the next planning cycle. This is where the loop closes — and where better decisions for the next cycle begin.
Business side compares the actual results against the desired outcome stated in the original user story. Did cancellation rates drop? Did the metric move? Was the problem actually solved? The answers to these questions determine what enters the next planning cycle.
The designer reviews how the feature is actually being used compared to how it was designed to be used. This is not about aesthetics — it is about whether the design decisions held up under real conditions: real users, real stress, real edge cases that were not anticipated.
QA monitors the feature in production. Pre-release testing covers known scenarios; production exposes unknown ones. QA is responsible for tracking reported issues, regressions, and edge cases that were not caught before release.
What good post-release research looks like